IBIS Macromodel Task Group Meeting date: 18 February 2020 Members (asterisk for those attending): Achronix Semiconductor Hansel Dsilva ANSYS: Dan Dvorscak * Curtis Clark Cadence Design Systems: Ambrish Varma Ken Willis Kumar Keshavan Intel: * Michael Mirmak Keysight Technologies: * Fangyi Rao * Radek Biernacki Ming Yan * Todd Bermensolo Marvell Steve Parker Mentor, A Siemens Business: * Arpad Muranyi Micron Technology: * Randy Wolff * Justin Butterfield SiSoft (Mathworks): * Walter Katz Mike LaBonte SPISim: * Wei-hsing Huang Teraspeed Labs: * Bob Ross The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - None. ------------- Review of ARs: - None. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the February 11 meeting. Michael moved to approve the minutes. Bob seconded the motion. There were no objections. ------------- New Discussion: DDR Clock Forwarding: Fangyi reviewed the current state of his in-progress draft of a new BIRD. The Definition of the Issue section states that clock forwarded DDR systems are the motivation for the BIRD. The BIRD proposes a new AMI_GetWave2() function and a new GetWave2_Exists Reserved Parameter. Note: During the meeting, two changes were made to the draft Fangyi presented. They were incorporated into the version he sent to ATM after the meeting (the version posted to the ATM work archives): 1. Arpad noted his comment, from a previous meeting, that the name of the new "wave_ref" argument to AMI_GetWave2() was misleading. Fangyi changed all references to "wave_ref" to "wave_clk". 2. The draft originally stated that GetWave_Exists and GetWave2_Exists could not both be true. That is, a model could provide one or the other (or neither) but not both. Walter suggested that it would be helpful to allow a model to provide both. If the DQS simulation were available, the new AMI_GetWave2() could be used. If the DQS were not available, the existing AMI_GetWave() could be used, and the model could figure out what it thought the best timing was. This would allow us to support existing functionality and add the new functionality. Fangyi agreed that we could relax the mutually exclusive requirement and allow the user/tool to choose which one to use if both were provided. Randy noted that he liked this approach and thought it would be easier for model makers. These changes were made to the draft, and the minutes below reflect them. - New AMI function AMI_GetWave2() - same signature as the existing AMI_GetWave(), except for the addition of a new wave_clk argument for passing in the clock waveform. - wave_clk definition - same size and sample interval as the existing wave argument - Algorithmic model can use this signal to control the timing of the DFE slicer. - If sample timing is based on wave_clk, the model should return clock_times based on wave_clk. - The model may internally process wave_clk before using it. - The EDA tool provides the wave_clk to the model. - In the case of a DQ Rx model in a DDR channel, the input waveform for wave_clk is the output wave from the corresponding DQS's Rx model. - Other arguments and the return value have the same definitions as AMI_GetWave(). Walter described the flow for the EDA tool in the GetWave2() case. The EDA tool will generate 1000 UI (for example) waveforms for DQ and DQS from the basic time-domain simulation flow. It will take the waveform for DQS -> pass it to the DQS Rx .dll GetWave()-> take the wave out (which must be the same length as the input) -> pass it to the DQ Rx .dll GetWave2() in the wave_clk argument along with the DQ waveform in the wave argument. Fangyi agreed. Arpad asked if DQ was the only model that needed a GetWave2() and whether some usage rules should be added to make it clear. Fangyi noted that his earlier presentation had mentioned that GetWave2() is only implemented in the DQ Rx model. DQS, command and address, etc., don't need a forwarded clock, and their models would only implement a traditional GetWave(). Arpad asked if the existing GetWave() section of the spec would also have to be modified to keep it consistent with what the new GetWave2() section stated. Fangyi agreed it probably would. Arpad noted we might have to search the spec for all references to GetWave(). Radek suggested we might be able to make a blanket statement that all references to GetWave() could mean GetWave() or GetWave2(). Radek suggested that we might consider a more descriptive name than AMI_GetWave2(), for example, AMI_GetWaveClock(). Walter again noted that this proposal requires that the output of the DQS model's GetWave() will become an input to the DQ model's GetWave2(), and it must have the same length as the DQ waveform. He said it's the model maker's responsibility to deal with any delays inserted in the DQS GetWave() that have to be accounted for in the DQ GetWave2(). He noted that a DQS will only have a CTLE and gain (amplification and frequency filtering). The frequency filtering implies that a delay will be inserted in the DQS path because of the way CTLEs are implemented. The assumption is that the DQ waveform going into the DQ Rx model and the DQS waveform going into the DQS Rx model were measured at their respective pads at the same time. The model maker takes that assumption, and then it's up to them to make sure any delays in the DQS path through the DQS model and the DQ and DQS paths through the DQ model are accounted for and things are aligned properly. Fangyi agreed, and said he thinks about the read and write cycles separately. In the write cycle, the DRAM is the Rx. It probably doesn't do any timing training. All the DQ-DQS alignment depends on the controller and would have been determined during write-leveling at bootup time. Similarly, the EDA tool could perform this task. The EDA tool could adjust the controller's DQ and DQS so they're aligned properly at the DRAM. Justin asked how the EDA tool will know that it has successfully aligned the clock and strobe. Will it expect feedback from the model? Fangyi said the EDA tool could assume that the DRAM expects the DQS and DQ to be center aligned. Randy asked if the model should assume that the DQS passed in as wave_clk has been shifted so that it's in the center of the DQ. Fangyi said the EDA tool's optimization should provide that, and then the model maker can do what they want internally. For example, the model could internally adjust the skew if the device has the capability. Randy noted that the controller shifts the strobe to align within a bit or byte, but then the controller also shifts each data bit to optimize it. So inside the DRAM those delays can be different for every bit. Randy said this is where we need some write-leveling training performed by the tool to figure out that alignment assuming the models build in all the actual delays. He noted that the model makers want to model the multiple UI shift in DQS relative to data so they can model the jitter effects. Fangyi agreed, and noted that the EDA tool could provide different ways of performing write-leveling training. It could assume the DRAM prefers center aligned DQS. It could also perform a sweep and look at BER levels to determine which phase relationship is best. In the real device, the controller typically looks at the error bit to determine write-leveling. Randy said it seems that it's still an open question how the EDA tools will deal this issue. If you just run a simulation without defining the write-leveling procedure you might end up clocking the DFE at the wrong location. Fangyi agreed. Fangyi noted that for the read cycle the controller is the Rx, and it typically has on-the-fly adjustment of the skew between DQ and DQS. It has an internal phase interpolator to optimize the phase relationship, and that behavior can be captured in the Rx model. Fangyi said he would send out the current draft for posting to the ATM work archives. Fangyi said he expected to have a more complete version in a week or two. BCI for statistical flow: Walter noted that he had nothing new to discuss, but he was working on an update to the DDR5 DQ Write protocol proposal. Discussion on "Gap in IBIS for sampling with statistical mode AMI models": Michael noted the goal of the presentation and the previous discussions was to address the issue with a BIRD. Walter agreed and noted that an email discussion on where to locate the clock in statistical analysis was ongoing. He said there were two possibilities being discussed: 1. The model tells the EDA tool where the eye should be sampled. It provides a "time" where the tool should sample. This time might not be trivial to define, and it would have to be defined carefully. 2. The alternative is for the model to specify which particular algorithm the EDA tool should use to determine that time. Arpad noted that he thought it made more sense for the model to return the time. He said that since the Rx model has a DFE, it must know where the UI begins since the DFE switches at the UI boundaries. So it would make more sense for model to tell the tool where the UI sits on the IR waveform. Walter said he also favored that approach. He noted that defining that time has to be done carefully. Arpad said he would send a reminder email to ATM. He noted that at the previous meeting we had planned to have a straw poll on which approach to choose. - Michael M.: Motion to adjourn. - Walter: Second. - Arpad: Thank you all for joining. AR: Fangyi to email his draft GetWave2() BIRD to ATM. AR: Arpad to send an email reminder about a straw poll on the sampling issues in statistical flow AMI. ------------- Next meeting: 25 February 2020 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives